TCP-splitter: reliable packet monitoring methods and apparatus for high speed networks

ABSTRACT

A method for obtaining data while facilitating keeping a minimum amount of state is provided. The method includes receiving at a first device an Internet Protocol (IP) frame sent from a second device to a third device wherein the first device is in a flow path between the second and third devices, the first device including at least one of an Application Specific Integrated Circuit (ASIC) and a Field Programmable Gate Array FPGA. The method also includes removing an embedded stream-oriented protocol frame including a header and a data packet from the received IP frame with at least one of the ASIC and the FPGA, and determining a validity of a checksum of the removed steam-oriented protocol header. The method also includes dropping the IP frame when the checksum is invalid, supplying a client application with data from the removed protocol frame when the checksum is valid, and sending an IP frame including the removed stream-oriented protocol frame to the third device from the first device when the checksum is valid.

BACKGROUND OF THE INVENTION

[0001] This invention relates generally to data transfer through anetwork and, more particularly, to the monitoring of data passingthrough the Internet.

[0002] At least some known protocol analyzers and packet capturingprograms have been around as long as there have been networks andprotocols to monitor. These known tools provide the ability to captureand save network data with a wide range of capabilities.

[0003] For example, one such program “tcpdump” available from theLawrence Berkeley National Laboratory (http://ee.lbl.gov/) allows forthe capture and storage of TCP packets. These known tools work well formonitoring data at low bandwidth rates, but the performance of theseprograms is limited because they execute in software. Post processing isrequired with these tools in order to reconstruct TCP data streams.

[0004] Accordingly, it would be desirable to provide a solution to datamonitoring that is implementable at high bandwidth rates.

BRIEF DESCRIPTION OF THE INVENTION

[0005] In one aspect, a method for obtaining data while facilitatingkeeping a minimum amount of state is provided. The method includesreceiving at a first device an Internet Protocol (IP) frame sent from asecond device to a third device wherein the first device is in a flowpath between the second and third devices, the first device including atleast one logic device. The method also includes removing an embeddedstream-oriented protocol frame including a header and a data packet fromthe received IP frame with the logic device, and determining a validityof a checksum of the removed steam-oriented protocol header. The methodalso includes dropping the IP frame when the checksum is invalid,actively dropping IP frames such that the first device always has anaccumulated in order content stream before the third device accumulatesthe in order stream, supplying a client application with data from theremoved protocol frame when the checksum is valid, and sending an IPframe including the removed stream-oriented protocol frame to the thirddevice from the first device when the checksum is valid.

[0006] In another aspect, an apparatus for facilitating keeping aminimum amount of state is provided. The apparatus includes at least oneinput port, at least one output port, and at least one logic deviceoperationally coupled to the input port and the output port. The logicdevice is configured to receive an Internet Protocol (IP) frame sentfrom a first device addressed to a second device, remove an embeddedstream-oriented protocol frame including a header and data packet fromthe received IP frame, classify the removed protocol frame as at leastone of a sequence number greater than expected classification, asequence number equal to expected, and a sequence number less thanexpected classification. The logic device is also configured to send anIP frame including the removed protocol frame to the second device whenthe classification is one of the sequence number less than expectedclassification and the sequence number equal to expected and drop thereceived IP frame including the removed protocol frame when theclassification is the sequence number greater than expectedclassification. The logic device is also configured to actively drop IPframes such that the apparatus always has an accumulated in ordercontent stream before the second device accumulates the in order stream.

[0007] In yet another aspect, an apparatus includes at least one inputport, at least one output port, and at least one reprogrammable device.The apparatus also includes at least one logic device operationallycoupled to the input port, the output port, and the reprogrammabledevice. The logic device is configured to receive an Internet Protocol(IP) frame sent from a first device addressed to a second device, removean embedded stream-oriented protocol frame including a header and a datapacket from the received IP frame, and determine if the removed protocolframe includes programming data. The logic device is also configured toreprogram the reprogrammable device when the removed protocol framecontains programming data, and send an IP frame including the removedprotocol frame to the second device.

[0008] In still another aspect, an apparatus includes at least one inputport, at least one output port, and at least one logic deviceoperationally coupled to the input port and the output port. The logicdevice is configured to receive an Internet Protocol (IP) frame sentfrom a first device addressed to a second device, remove an embeddedstream-oriented protocol frame including a header and a data packet fromthe received IP frame, and determine if the removed protocol frameincludes data representing a quality of service (QoS) algorithm. Thelogic device is further configured to supply a client application withdata from the removed protocol frame when the removed protocol includesQoS data, and send an IP frame including the removed protocol frame tothe second device.

[0009] In yet still another aspect, a network including a plurality ofswitching devices operationally coupled to each other is provided. Atleast some of the switching devices including at least one logic deviceconfigured to monitor stream-oriented network traffic for FieldProgrammable Gate Array (FPGA) programming data, reprogram at least oneof itself and a FPGA coupled to said logic device upon receipt of theFPGA programming data, and retransmit the FPGA programming data backonto the network such that other switching devices can reprogramthemselves using the FPGA programming data.

[0010] In still yet another aspect, a method for distributing data isprovided. The method including receiving at a first device an InternetProtocol (IP) frame sent from a second device to a third device whereinthe first device is in a flow path between the second and third devices,wherein the first device includes an Integrated Circuit (IC). The methodalso includes removing an embedded protocol frame from the received IPframe with the IC, supplying a client application with data from theremoved protocol frame, analyzing the data supplied to the clientapplication, and sending an IP frame including the removed protocolframe to the third device from the first device only after analyzing thedata.

[0011] In one aspect, a method for distributing data on a network usinga single TCP/IP source, a single destination and one or moreintermediate hardware based monitoring nodes is provided. The methodincludes receiving at a first device an Internet Protocol (IP) framesent from a second device to a third device wherein the first device isin a flow path between the second and third devices, the first deviceincluding at least one logic device. The method also includes removingan embedded Transmission Control Protocol (TCP) frame from the receivedIP frame with the logic device, supplying a client application with datafrom the removed protocol frame and sending an IP frame including theremoved protocol frame to the third device from the first device afterperforming an analysis on the removed frame.

[0012] In another aspect, a method for identifying and selectivelyremoving data on a data transmission system is provided. The methodincludes receiving at a first device an Internet Protocol (IP) framesent from a second device to a third device wherein the first device isin a flow path between the second and third devices, the first deviceincluding at least one logic device, and actively dropping IP framesaddressed to the third device sent by the second device such that thefirst device always has an accumulated in order content stream beforethe third device accumulates the in order content stream.

[0013] In yet another aspect, a dynamically reconfigureable datatransmission system, having an apparatus including at least one inputport, at least one output port, and at least one logic deviceoperationally coupled to the input port and the output port. The logicdevice is configured to receive an Internet Protocol (IP) frame sentfrom a first device addressed to a second device, remove an embeddedprotocol frame from the received IP frame, and determine if the removedprotocol frame includes Field Programmable Gate Array (FPGA) programmingdata. The logic device is also configured to supply a client applicationwith data from the removed protocol frame when the removed protocolincludes FPGA programming data such that the application receives acontent stream in order, and send an IP frame including the removedprotocol frame to the second device.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014]FIG. 1 is a high level view of the data flow through an embodimentof a TCP-Splitter.

[0015]FIG. 2 is a low-level view of data flow though an embodiment of aTCP-splitter.

[0016]FIG. 3 is a perspective view of a Field-programmable Port Extender(FPX) module.

[0017]FIG. 4 is a schematic view of the FPX module shown in FIG. 3.

[0018]FIG. 5 illustrates a plurality of workstations connected to aremote client across the Internet through a node including aTCP-Splitter coupled to a monitoring client application.

[0019]FIG. 6 illustrates a plurality of TCP-Splitter implemented FPXmodules, as shown in FIGS. 3 and 4, in series between a programmingdevice and a endpoint device forming a network.

DETAILED DESCRIPTION OF THE INVENTION

[0020]FIG. 1 is a high level view of the data flow through an embodimentof a TCP-Splitter 10. A plurality of Internet Protocol (IP) frames 12enter into TCP-Splitter 10 from a source device 14 and frames 12 areaddressed to a destination device 16. IP frames 12 each include an IPheader 18 and a TCP frame including a TCP header and a data packet. TheTCP header is removed, the packet is classified to retrieve Flow State,and then the packet is sent as a byte stream to a client application 20.An IP frame including the embedded TCP frame is also sent to destinationdevice 16. Accordingly, the splitting of the TCP frame from the IP frameis transparent to devices 14 and 16. In one embodiment, clientapplication 20 counts how many bits are being transferred in a TCPexchange. Additionally, client application 20 is provided with TCPheader information and/or IP header information, and in one embodiment,the header information is used to bill a user on a bit transferredbasis. In another embodiment, client application 20 has access toreference data and, in real time, compares the byte stream of TCPtransferred data provided to client application 20 with the referencedata to provide a content matching such as for example but not limitedcontent matching as described in co-pending patent application Ser. No.10/152,532 and now-abandoned application Ser. No. 10/037,543, which arehereby incorporated herein in their entirety. In one embodiment, uponfinding a particular match with a predefined reference data,TCP-splitter 10 stops all data flow from a particular IP address, alldata flow to a particular IP address, and/or all data flow thoughTCP-splitter 10. In other embodiments, client application 20 monitorsdata through TCP-Splitter for security purposes, for keyword detection,for data protection, for copyright protection, and/or for watermarkdetection (and/or other types of embedded digital signatures). In oneembodiment, a delay is utilized such that the data is analyzed asdescribed above before an IP frame including the removed TCP frame issent to the destination device. Accordingly, TCP-Splitter 10 allows foractions to be taken in real time processing. In other words,TCP-Splitter 10 allows for arbitrary actions to be taken by the clientapplication before the IP frame is sent to the destination device. Theseactions include delaying transmission of the IP frame and stoppingtransmission of the IP frame. Additionally, in some placements, IPframes 12 can be wrapped with other protocol wrappers such as an ATMAdaptation Layer 5 (AAL5) frame wrapper 22 and an Asynchronoustransmission mode (ATM) Cell wrapper 24.

[0021] TCP-Splitter 10 is not implemented in software, ratherTCP-Splitter 10 is implemented with combinational logic and finite statemachines in a logic device. As used herein a logic device refers to anApplication Specific IC (ASIC) and/or a Field Programmable Gate Array(FPGA), and excludes processors. In the FPGA prototype, TCP-splitter 10processes packets at line rates exceeding 3 gigabits per second (Gbps)and is capable of monitoring 256 k TCP flows simultaneously. However,TCP-Splitter 10 is not limited in the number of simultaneous TCP flowsTCP-Splitter 10 is capable of monitoring and while 256 k flows wasimplemented in the prototype built, additional flows can easily bemonitored by increasing the amount of memory utilized. Additionally,TCP-splitter 10 delivers a consistent byte stream for each TCP flow toclient application 20. As explained in greater detail below,TCP-splitter 10 processes data in real time, provides client application20 the TCP packets in order, and eliminates the need for largereassembly buffers. Additionally, by providing the TCP content in order,TCP-Splitter facilitates keeping a minimal amount of state.

[0022]FIG. 2 is a low level view of data flow though an embodiment of aTCP-splitter 30 illustrating a TCP input section 32 and a TCP outputsections 34. Input section 32 includes a Flow classifier 36, a ChecksumEngine 38, an Input State Machine 40, a Control First In-First Out(FIFO) buffer 42, a Frame FIFO buffer 44, and an Output State Machine46. TCP output section 34, includes a Packet Routing engine 48operationally coupled to a Client Application 50 and an IP output stack52.

[0023] In use, data is delivered to an input stack 54 operationallycoupled to TCP input section 32. Flow Classifier 36, Checksum Engine 38,Input State Machine 40, Control FIFO 42, and Frame FIFO 44 all processIP packet data received from the IP protocol wrapper. Output StateMachine 46 is responsible for clocking data out of the control and frameFIFOs 42 and 44, and into output section 34. The input interface signalsto TCP-Input section 32 are as follows:

[0024] IN 1 bit clock

[0025] IN 1 bit reset

[0026] IN 32 bit data word

[0027] IN 1 bit data enable

[0028] IN 1 bit start of frame

[0029] IN 1 bit end of frame

[0030] IN 1 bit start of IP payload

[0031] IP frames are clocked into input section 32 thirty-two data bitsat a time. As data words are clocked in, the data is processed by InputState Machine 40 and buffered for one clock cycle. Input State Machine40 examines the content of the data along with the control signals inorder to determine the next state.

[0032] The output of Input State Machine 40 is the current state and thecorresponding data and control signals for that state. This data isclocked into Flow Classifier 36, Checksum Engine 38, and Frame FIFO 44.

[0033] Flow Classifier 44 performs TCP/IP flow classification, verifiesthe sequence number, and maintains state information for this flow.Output signals of Flow Classifier 44 are (1) a 1 bit indication ofwhether or not this is a TCP packet, (2) a variable length flowidentifier (currently eighteen bits), (3) a 1 bit indication of whetherof not this is a new TCP flow, (4) a 1 bit indication of whether or notthis packet should be forwarded, (5) a 1 bit indication of whether thesequence number was correct, and (6) a 1 bit indication of the end of aTCP flow.

[0034] Checksum Engine 38 verifies the TCP checksum located in the TCPheader of the packet. The output of the checksum engine is a 1-bitindication whether of not the checksum was successfully verified. FrameFIFO 44 stores the IP packet while Checksum Engine 38 and FlowClassifier 36 are operating on the packet. Frame FIFO 44 also stores a 1bit indication of the presence of TCP data, a 1 bit indication of thestart of frame, a 1 bit indication of the end of frame, a 1 bitindication of the start of the IP packet payload, a 1 bit indication ofwhether or not there is valid TCP data, and a 2 bit indication of thenumber of valid bytes in the data word. The packet is stored so that thechecksum and flow classifier results can be delivered to the outboundsection 34 along with the start of the packet.

[0035] Once the flow has been classified and the TCP checksum has beencomputed, information about the current frame is written to Control FIFO42. This data includes the checksum result (pass or fail), a flowidentifier (currently 18 bits), an indication of whether or not this isthe start of a new flow, an indication of whether or not the sequencenumber matched the expected sequence number, a signal to indicatewhether or not the frame should be forwarded, and a 1 bit indication ofwhether or not this is the end of a flow. Control FIFO 42 facilitatesholding state information of smaller frames while preceding largerframes are still being clocked out of Frame FIFO 44 for outboundprocessing.

[0036] Output State Machine 46 is responsible for clocking data out ofthe Control and Frame FIFOs 42 and 44, and into output section 34 ofTCP-Splitter 30. Upon detecting a non-empty Control FIFO 42, outputstate machine 46 starts clocking the next IP frame out of Frame FIFO 44.This frame data along with the control signals from Control FIFO 42 exitTCP-Input section 32 and enter TCP-Output section 34.

[0037] TCP-Splitter 30 uses a flow classifier that can operate at highspeed and has minimal hardware complexity. In an exemplary embodiment aflow table with a 256 k element array contained in a low latency staticRAM chip is used. Each entry in the table contains thirty-three bits ofstate information. An eighteen-bit hash of the source IP address, thedestination IP address, the source TCP port, and the destination TCPport are used as the index into the flow table. The detection of a TCPFIN flag signals the end of a TCP flow and the hash table entry for thatparticular flow is cleared. Other classifiers can be used to identifytraffic flows for TCP-Splitter 30. For example, SWITCHGEN (as describedin “Pattern Matching in Reconfigurable Logic for Packet Classification”,ACM Cases, 2001, A. Johnson and K. Mackenzie) is a tool which transformspacket classification into reconfigurable hardware based circuit designand can be used with TCP-splitter 30. A Recursive Flow Classification(RFC) algorithm can also be used with TCP-Splitter and is another highperformance classification technique that optimizes rules by removingredundancy. The design of TCP-Splitter 30 does not impose anyrestrictions on the flow classification technique utilized and can beused with any flow classifier.

[0038] In an exemplary embodiment, output-processing section 34 ofTCP-Splitter 30 is responsible for determining how a packet should beprocessed. The input interface signals to output section 34 are asfollows:

[0039] IN 1 bit clock

[0040] IN 1 bit reset

[0041] IN 32 bit data word

[0042] IN 1 bit data enable

[0043] IN 1 bit start of frame

[0044] IN 1 bit end of frame

[0045] IN 1 bit start of IP payload

[0046] IN 1 bit TCP data enable

[0047] IN 2 bit number of valid data bytes

[0048] IN 1 bit TCP protocol indication

[0049] IN 1 bit checksum passed

[0050] IN 18 bit flow identifier

[0051] IN 1 bit new flow indication

[0052] IN 1 bit forward frame indication

[0053] IN 1 bit correct sequence number

[0054] IN 1 bit data is valid

[0055] IN 1 bit end of flow

[0056] There are three possible choices for packet routing. Packets canbe (1) passed on to the outbound IP stack only, (2) passed both to theoutbound IP stack and to client application 50, or (3) discarded(dropped). The rules for processing packets are as follows:

[0057] All non-TCP packets (i.e., classified as non-TCP) are sent to theoutbound IP stack.

[0058] All TCP packets with invalid checksums (i.e., classified asinvalid TCP checksum) are dropped.

[0059] All TCP packets with sequence numbers less than the currentexpected sequence number (i.e., classified as sequence number less thanexpected) are sent to the outbound IP stack.

[0060] All TCP packets with sequence numbers greater than the currentexpected sequence number (i.e., classified as sequence number greaterthan expected) are dropped (i.e., discarded and not sent to eitherclient application 50 or the outbound IP stack).

[0061] All TCP synchronization (TCP-SYN) packets are sent to theoutbound IP stack.

[0062] All other packets (classified as else) are forwarded both to theoutbound IP stack and client application 50. Note that when the TCPpacket has a sequence number equal to expected and has a valid checksum,then that packet is classified as else and sent to the outbound IP stackas well as to client application 50.

[0063] A client interface (not shown) is between client application 50and TCP output section 34. The client interface provides a hardwareinterface for application circuits. Only data that is valid,checksummed, and in-sequence for each specific flow is passed to clientapplication 50. This allows the client to solely process the consistentstream of bytes from the TCP connection. All of the packet's protocolheaders are clocked into client application 50 along with astart-of-header signal so that the client can extract information fromthese headers. This eliminates the need to store header information, butstill allows the client access to this data. Client application 50 doesnot sit in the network data path and therefore does not induce any delayinto the packets traversing the network switch. This allows the clientapplication to have arbitrary complexity without affecting thethroughput rate of TCP-splitter 30. The client interface contains thefollowing signals:

[0064] IN 1 bit clock

[0065] IN 1 bit reset

[0066] IN 32 bit data word

[0067] IN 1 bit data enable

[0068] IN 1 bit start of frame

[0069] IN 1 bit end of frame

[0070] IN 1 bit start of IP payload

[0071] IN 1 bit TCP data enable

[0072] IN 2 bit number of valid data bytes

[0073] IN 18 bit flow identifier

[0074] IN 1 bit new flow indication

[0075] IN 1 bit end of flow

[0076] OUT 1 bit flow control

[0077] Client application 50 can generate a flow control signal thatwill stop the delivery of cells. In one embodiment, this signal is notprocessed by TCP-Splitter 30, but is passed on to the IP wrapper drivingthe ingress of IP packets. In another embodiment, this signal isprocessed by TCP-Splitter 30.

[0078] In the embodiment where TCP-Splitter 30 does not process the flowcontrol signals, there is a delay in the cessation of the flow of datawords into client application 50 while the flow control signal is beingprocessed by the lower protocol layers. Since TCP-Splitter 30 does notact upon the flow control signal, data continues to flow until allbuffers of TCP-Splitter 30 are empty. Client application 50 isconfigured to either handle data at line rates or is capable ofbuffering 1500 bytes worth of data after the flow control signal isasserted.

[0079] Because Transmission Control Protocol/Internet Protocol (TCP/IP)is the most commonly used protocol on the Internet, it is utilized bynearly all applications that require reliable data communications on anetwork. These applications include Web browsers, FTP, Telnet, SecureShell, and many others. High-speed network switches currently operate atOC-48 (2.5 Gb/s) line rates, while faster OC-192 (10 Gb/s) and OC-768(40 Gb/s) networks are on the horizon. New types of networking equipmentrequire the ability to monitor and interrogate the data contained inpackets flowing through this equipment. TCP-Splitter 30 provides aneasily implementable solution for monitoring at these increasedbandwidths.

[0080] In one embodiment, and as explained in greater detail below,TCP-Splitter 30 provides a reconfigurable hardware solution whichprovides for the monitoring of TCP/IP flows in high speed activenetworking equipment. The reconfigurable hardware solution isimplemented using Very High Speed Integrated Circuit (VHSIC) Hard-wareDescription Language (VHDL) for use in ASICs or Field Programmable GateArrays (FPGAs). The collection of VHDL code that implements this TCP/IPmonitoring function is also called TCP-Splitter in addition to thehardware itself (i.e., 10 and 30). This name stems from the idea thatthe TCP flow is being split into two directions. One copy of eachnetwork data packet is forwarded on toward the destination host. Anothercopy is passed to a client application monitoring TCP/IP flows. In analternative embodiment, the copy that is passed to the clientapplication is rewrapped with an IP wrapper to form an IP frame that isforwarded to the destination host. In order to provide for the reliabledelivery of a stream of data into a client application, a TCP connectiononly needs to be established that transits through the device monitoringthe data. The bulk of the work for guaranteed delivery is managed by theTCP endpoints, not by the logic on the network hardware. This eliminatesthe need for a complex protocol stack within the reconfigurable hardwarebecause the retransmission logic remains at the connection endpoints,not in the active network switch.

[0081] TCP-Splitter 30 is a lightweight, high performance circuit thatcontains a simple client interface that can monitor a nearly unlimitednumber of TCP/IP flows simultaneously. The need for reassembly buffersis eliminated because all frames for a particular flow transit thenetworking equipment in order. Because there is no guarantee that TCPframes will traverse the network in order, some action will have to takeplace when packets are out of order. As explained above, by activelydropping out of order packets, a TCP byte stream is generated for theclient application without requiring reassembly buffers. If a missingpacket is detected, subsequent packets are actively dropped until themissing packet is retransmitted. This ensures in-order packet flowthrough the switch. Therefore a monitoring device always has anaccumulated in order content stream before a destination deviceaccumulates the in order content stream.

[0082] This feature forces the TCP connections into a Go-Back-N slidingwindow mode when a packet is dropped upstream of the monitoring node(e.g., the node where TCP-Splitter is positioned). The Go-Back-Nretransmission policy is widely used on machines throughout theInternet. Many implementations of TCP, including that of Windows 98,FreeBSD 4.1, and Linux 2.4, use the Go-Back-N retransmission logic. Thebenefit on the throughput is dependent on the specific TCPimplementations being utilized at the endpoints. In instances where thereceiving TCP stack is performing Go-Back-N sliding window behavior, theactive dropping of frames may improve overall network throughput byeliminating packets that will be discarded by the receiver.

[0083] Typically, TCP-Splitter 30 is placed in the network where allpackets of monitored flows will pass. All packets associated with aTCP/IP connection being monitored then passes through the networkingnode where monitoring is taking place. It would otherwise be impossibleto provide a client application with a consistent TCP byte stream from aconnection if the switch performing the monitoring only processed afraction of the TCP packets. In general, this requirement is true at theedge routers but not true for interior nodes of the Internet. Thisstrategic placement of TCP-Splitter can be easily accomplished inprivate networks where the network has been designed to pass traffic ina certain manner.

[0084]FIG. 3 is a perspective view and FIG. 4 is a schematic view of aField-programmable Port Extender (FPX) module 60 configured to implementa TCP-Splitter as described above. Module 60 includes a NetworkInterface Device (NID) 62 operationally coupled to a ReprogrammableApplication Device (RAD) 64. NID 62 is configured to program and/orreprogram RAD 64. Module 60 also includes a plurality of memoriesincluding a static RAM 66, a Synchronous DRAM 68, and a PROM 70operationally coupled to at least one of NID 62 and RAD 64. In anexemplary embodiment, NID 62 includes a FPGA such as a XCV600E FPGAcommercially available from Xilinx, San Jose Calif., and RAD 64 includesa FPGA such as a XCV2000E FPGA also available from Xilinx.

[0085] In use, module 60 monitors network traffic and send TCP datastreams to a client application in order. Because module 60 implementsthe TCP-Splitter in a FPGA, upon receipt of FPGA programming data theTCP-Splitter can reprogram itself and send the FPGA programming data toother TCP-splitters in a flow path between a sending device and adestination device. Additionally, module 60 can reprogram the router toprocess the traffic flow differently than before. Also, because the datais passed along to other TCP-Splitters, the overall QoS of a network isquickly and easily changeable. In other words, QoS policies, as known inthe art, are easily and quickly changed in networks including aTCP-Splitter as herein described. Accordingly, the reprogrammed routerprioritizes network traffic based on the flow. Additionally, theTCP-Splitter can include a plurality of reprogrammable circuits such asFPGAs and can monitor the TCP flows for different things substantiallysimultaneously. For example, one flow contains data in order for aclient application to count bits, while another flow contains data inorder for another client application to perform content matching, whileanother flow contains data for reprogramming an FPGA. Also, a pluralityof FPGAs can be coupled to each other such that upon receipt by at leastone of an ASIC and a FPGA of FPGA programming data, the ASIC or FPGAreceiving the data uses the data to reprogram the FPGAs.

[0086]FIG. 5 illustrates a plurality of workstations 80 connected to aremote client 82 across the Internet 84 through a node 86 including aTCP-Splitter (not shown in FIG. 4) coupled to a Monitoring clientapplication 88. All traffic from remote client 82 or any other device onthe Internet 84 to or from workstations 80 passes through node 86 and ismonitored with the TCP-Splitter coupled to client application 88.

[0087]FIG. 6 illustrates a plurality of TCP-Splitter implemented FPXmodules 60 (Shown in FIGS. 3 and 4) in series between a programmingdevice 90 and an endpoint device 92 forming a network 94.

[0088] In use, programming device 90 transmits programming data via astream-oriented protocol using the Internet Protocol (IP) to send thedata to endpoint device 92. Each FPX module 60 receives a plurality ofIP frames addressed to endpoint device 92, removes the embeddedstream-oriented protocol frame from the IP frame, and provides a clientapplication the removed stream-oriented protocol frame. Each FPX module60 sends an IP frame including the removed protocol frame back ontonetwork 92. Accordingly, with one transmission stream made fromprogramming device 90 to endpoint device 92, a plurality of intermediatedevices (modules 60) receive programming data either to reprogramthemselves (modules 60) or to reprogram any attached devices. Becausethe programming data is split (i.e., sent to the client application andsent back on network 94 addressed to endpoint device 92), TCP-Splitterimparts the ability to easily and quickly reconfigure a network of anysize. As used herein, a stream-oriented protocol refers to all protocolsthat send data as a stream of packets such as TCP as opposed tonon-stream-oriented protocols such as UDP where a single packet containsthe entire message.

[0089] While the invention has been described in terms of variousspecific embodiments, those skilled in the art will recognize that theinvention can be practiced with modification within the spirit and scopeof the claims.

What is claimed is:
 1. A method for obtaining data while facilitatingkeeping a minimum amount of state, said method comprising: receiving ata first device an Internet Protocol (IP) frame sent from a second deviceto a third device wherein the first device is in a flow path between thesecond and third devices, the first device including at least one logicdevice; removing an embedded stream-oriented protocol frame including aheader and a data packet from the received IP frame with the logicdevice; determining a validity of a checksum of the removedsteam-oriented protocol header; dropping the IP frame when the checksumis invalid; actively dropping IP frames such that the first devicealways has an accumulated in order content stream before the thirddevice accumulates the in order stream; supplying a client applicationwith data from the removed protocol frame when the checksum is valid;and sending an IP frame including the removed stream-oriented protocolframe to the third device from the first device when the checksum isvalid.
 2. A method in accordance with claim 1 wherein sending an IPframe including the removed protocol frame comprises: classifying theremoved protocol frame as at least one of a sequence number greater thanexpected classification, a sequence number equal to expectedclassification, and a sequence number less than expected classification;sending an IP frame including the removed protocol frame to the thirddevice from the first device when the classification is one of thesequence number less than expected classification and the sequencenumber equal to expected classification; and dropping an IP frameincluding the removed protocol frame when the classification is thesequence number greater than expected classification.
 3. A method inaccordance with claim 1 wherein removing an embedded stream-orientedprotocol frame from the received IP frame with the logic devicecomprises removing a Transmission Control Protocol (TCP) frame from thereceived IP frame with the logic device
 4. A method in accordance withclaim 1 further comprising classifying the removed embeddedstream-oriented protocol frame as at least one of a sequence numbergreater than expected classification, a sequence number less thanexpected classification, an invalid Transmission Control Protocol (TCP)checksum classification, a non-TCP classification, a TCP synchronization(TCP SYN) classification, and an else classification.
 5. A method inaccordance with claim 4 wherein supplying a client application with datafrom the removed protocol frame comprises supplying a client applicationwith data from the removed protocol frame only when the classificationis else.
 6. A method in accordance with claim 5 wherein sending an IPframe including the removed protocol frame to the third device from thefirst device comprises sending an IP frame including the removedprotocol header to the third device from the first device only when theclassification is at least one of non-TCP, TCP SYN, sequence number lessthan expected, and else.
 7. A method in accordance with claim 6 furthercomprising dropping the received IP frame when the classification is atleast one of invalid TCP checksum and sequence number greater thanexpected.
 8. A method in accordance with claim 1 wherein supplying aclient application with data from the removed protocol frame comprisessupplying a client application with data from the removed protocol framesuch that content of a Transmission Control Protocol (TCP) stream isprovided to a client application in order.
 9. A method in accordancewith claim 1 wherein sending an IP frame including the removed protocolframe to the third device from the first device comprises sending the IPframe received by the first device from the first device to the thirddevice.
 10. A method in accordance with claim 1 wherein supplying aclient application with data from the removed protocol frame comprisessupplying a client application that counts bits with data from theremoved protocol frame.
 11. A method in accordance with claim 1 whereinsupplying a client application with data from the removed protocol framecomprises supplying a client application with data from the removedprotocol frame wherein the client application compares the supplied datawith reference data to perform content matching.
 12. A method inaccordance with claim 1 wherein supplying a client application with datafrom the removed protocol frame when the checksum is valid comprisessupplying a client application with data from the removed protocol framecomprising FPGA programming data.
 13. An apparatus for facilitatingkeeping a minimum amount of state, said apparatus comprising: at leastone input port; at least one output port; and at least one logic deviceoperationally coupled to said input port and said output port, saidlogic device configured to: receive an Internet Protocol (IP) frame sentfrom a first device addressed to a second device; remove an embeddedstream-oriented protocol frame including a header and data packet fromthe received IP frame; classify the removed protocol frame as at leastone of a sequence number greater than expected classification, asequence number equal to expected classification, and a sequence numberless than expected classification; send an IP frame including theremoved protocol frame to the second device when the classification isone of the sequence number less than expected classification and thesequence number equal to expected classification; drop the received IPframe including the removed protocol frame when the classification isthe sequence number greater than expected classification; and activelydrop IP frames such that said apparatus always has an accumulated inorder content stream before the second device accumulates the in orderstream.
 14. An apparatus in accordance with claim 13 wherein said logicdevice further configured to: remove a Transmission Control Protocol(TCP) frame from the received IP frame; determine a validity of a TCPchecksum of the removed TCP frame; drop the IP frame when the TCPchecksum is invalid; and send an IP frame including the removed TCPframe to the second device when the TCP checksum is valid.
 15. Anapparatus in accordance with claim 13 wherein said logic device furtherconfigured to classify the removed protocol frame as at least one of asequence number greater than expected classification, a sequence numberless than expected classification, an invalid TCP checksumclassification, a non-TCP classification, a TCP synchronization (TCPSYN) classification, and an else classification.
 16. An apparatus inaccordance with claim 15 wherein said logic device further configured tosupply a client application with data from the removed protocol frameonly when the classification is the else classification.
 17. Anapparatus in accordance with claim 15 wherein said logic device furtherconfigured to send an IP frame including the removed protocol frame tothe second device only when the classification is at least one of thenon-TCP classification, the TCP SYN classification, the sequence numberless than expected classification, and the else classification.
 18. Anapparatus in accordance with claim 15 wherein said logic device furtherconfigured to drop the received IP frame when the classification is atleast one of the invalid TCP checksum classification and the sequencenumber greater than expected classification.
 19. An apparatus inaccordance with claim 13 wherein said logic device further configured tosupply a client application with data from the removed protocol framesuch that content of a Transmission Control Protocol (TCP) stream isprovided to a client application in order.
 20. An apparatus inaccordance with claim 13 wherein said logic device further configured tosend to the second device an IP frame comprising the IP frame receivedby said IC.
 21. An apparatus in accordance with claim 13 wherein saidlogic device further configured to supply a client application thatcounts bits with data from the removed protocol frame.
 22. An apparatusin accordance with claim 13 wherein said logic device further configuredto supply a client application with data from the removed protocol framewherein the client application compares the supplied data with referencedata to perform content matching.
 23. An apparatus in accordance withclaim 13 further comprising a Field Programmable Gate Array (FPGA)operationally coupled to said logic device, said logic device configuredto reprogram said FPGA.
 24. An apparatus in accordance with claim 23wherein said FPGA operationally coupled to said input port and saidoutput port.
 25. An apparatus comprising: at least one input port; atleast one output port; and at least one reprogrammable device; at leastone logic device operationally coupled to said input port, said outputport, and said reprogrammable device, said logic device configured to:receive an Internet Protocol (IP) frame sent from a first deviceaddressed to a second device; remove an embedded stream-orientedprotocol frame including a header and a data packet from the received IPframe; determine if the removed protocol frame includes programmingdata; reprogram said reprogrammable device when the removed protocolframe contains programming data; and send an IP frame including theremoved protocol frame to the second device.
 26. An apparatuscomprising: at least one input port; at least one output port; and atleast one logic device operationally coupled to said input port and saidoutput port, said logic device configured to: receive an InternetProtocol (IP) frame sent from a first device addressed to a seconddevice; remove an embedded stream-oriented protocol frame including aheader and a data packet from the received IP frame; determine if theremoved protocol frame includes data representing at least part of aquality of service (QoS) algorithm; supply a client application withdata from the removed protocol frame when the removed protocol includesdata representing at least part of a QoS algorithm; and send an IP frameincluding the removed protocol frame to the second device.
 27. Anapparatus in accordance with claim 26 wherein said logic device furtherconfigured to reconfigure at least one QoS policy in accordance with theQoS data supplied to the client application.
 28. A network comprising aplurality of switching devices operationally coupled to each other, atleast some of said switching devices comprising at least one logicdevice configured to: monitor stream-oriented network traffic for FieldProgrammable Gate Array (FPGA) programming data; reprogram at least oneof itself and a FPGA coupled to said logic device upon receipt of theFPGA programming data; and retransmit the FPGA programming data backonto the network such that other switching devices can reprogram atleast one of themselves and an attached FPGA using the FPGA programmingdata.
 29. A network in accordance with claim 28 wherein to monitorstream-oriented network traffic for FPGA programming data, at least someof said switching devices configured to: receive an Internet Protocol(IP) frame sent from a first device addressed to a second device; removean embedded stream-oriented protocol frame from the received IP frame;and determine if the removed protocol frame includes FPGA programmingdata.
 30. A network in accordance with claim 28 wherein to monitorstream-oriented network traffic for FPGA programming data, at least someof said switching devices configured to: receive an Internet Protocol(IP) frame sent from a first device addressed to a second device; removean embedded stream-oriented protocol frame from the received IP frame;determine if the removed steam-oriented protocol frame includes FPGAprogramming data; supply a client application with data from the removedprotocol frame when the removed protocol includes FPGA programming data;and send an IP frame including the removed protocol frame to the seconddevice.
 31. A method for distributing data, said method comprisingreceiving at a first device an Internet Protocol (IP) frame sent from asecond device to a third device wherein the first device is in a flowpath between the second and third devices, the first device including anIntegrated Circuit (IC); removing an embedded protocol frame from thereceived IP frame with the IC; supplying a client application with datafrom the removed protocol frame; analyzing the data supplied to theclient application; and sending an IP frame including the removedprotocol frame to the third device from the first device only afteranalyzing the data.
 32. A method for distributing data on a networkusing a single TCP/IP source, a single destination and one or moreintermediate hardware based monitoring nodes, said method comprising:receiving at a first device an Internet Protocol (IP) frame sent from asecond device to a third device wherein the first device is in a flowpath between the second and third devices, the first device including alogic device; removing an embedded Transmission Control Protocol (TCP)frame from the received IP frame with the logic device; supplying aclient application with data from the removed protocol frame; andsending an IP frame including the removed protocol frame to the thirddevice from the first device after performing an analysis on the removedframe.
 33. A method for identifying and selectively removing data on adata transmission system, said method comprising: receiving at a firstdevice an Internet Protocol (IP) frame sent from a second device to athird device wherein the first device is in a flow path between thesecond and third devices, the first device including a logic device;actively dropping IP frames addressed to the third device sent by thesecond device such that the first device always has an accumulated inorder content stream before the third device accumulates the in ordercontent stream.
 34. A dynamically reconfigureable data transmissionsystem, having an apparatus comprising: at least one input port; atleast one output port; and at least one logic device operationallycoupled to said input port and said output port, said logic deviceconfigured to: receive an Internet Protocol (IP) frame sent from a firstdevice addressed to a second device; remove an embedded protocol framefrom the received IP frame; determine if the removed protocol frameincludes Field Programmable Field Array (FPGA) programming data; supplya client application with data from the removed protocol frame when theremoved protocol includes FPGA programming data such that theapplication receives a content stream in order; and send an IP frameincluding the removed protocol frame to the second device.